HNB Gateway in UMTS Network

 

 

The Cisco® ASR 5000 Platform provides 3GPP wireless carriers with a flexible solution that functions as a Home NodeB Gateway (HNB-GW) in HNB Access Network to connect UEs with existing UMTS networks.

The Home NodeB Gateway works as an gateway for Home NodeBs (HNBs) to access the core networks. The HNB-GW concentrates connections from a large amount of HNBs through IuH interface and terminates the connection to existing Core Networks (CS or PS) using standard Iu (IuCS or IuPS) interface.

This overview provides general information about the HNB Gateway including:

•	Product Description

•	Product Specification

•	Network Deployment and Interfaces

•	Features and Functionality - Base Software

•	Features and Functionality - Optional Enhanced Feature Software

•	How HNB-GW Works

•	Supported Standards

 

Product Description

The Home NodeB Gateway is the HNB network access concentrator used to connect the Home NodeBs (HNBs)/Femto Access Point (FAP) to access the UMTS network through HNB Access Network. It aggregates Home Node-B or Femto Access Points to a single network element and then integrates them into the Mobile Operators Voice, Data and Multimedia networks.

Femtocell is an important technology and service offering that enables new Home and Enterprise service capabilities for Mobile Operators and Converged Mobile Operators (xDSL/Cable/FFTH plus Wireless). The Femtocell network consists of a plug-n-play customer premise device generically called an Home NodeB (HNB) with limited range radio access in home or Enterprise. The HNB will auto-configure itself with the Operators network and the user can start making voice, data and multimedia calls.

The figure given describes a high level view of UMTS network with Femtocell and HNB-GW.

HNB-GW Deployment in 3G UMTS Network

Once a secure tunnel has been established between the HNB and the SeGW and the HNB has been configured by the HMS, the Operator has to connect the Femtocell network to their Core Network and services. There are several interworking approaches to Circuit Switch (CS) and Packet Switch (PS) domains. One approach is to make the Femtocell network appear as a standard Radio Access Network (RAN) to the Core Network. In addition to the HNB, SeGW and HMS the RAN approach requires a network element generically called a Femto Gateway (FGW/HNB-GW). The HNB-GW provides interworking and aggregation of large amount of Femtocell sessions toward standard CN interfaces (IuPS/IuCS). In this approach services and mobility are completely transparent to CN elements (e.g. MSC, xGSN).

The other approach is to connect the Femtocell to an IMS Network to provide CS services to subscribers when on the Femtocell and deploy a new network element generically called a Convergence Server to provide service continuity and mobility over standard interfaces at the MSC layer (e.g GSM-MAP, IS-41). These two approaches are clearly different in how CS based services and mobility are achieved.

In accordance with 3GPP standard, the HNB-GW provides following functions and procedures in UMTS core network:

•	HNB Registration/De-registration Function

•	UE Registration/De-registration Function for HNB

•	IuH User-plane Management Functions

•	IuH User-plan Transport Bearer Handling

•	Iu Link Management Functions

Important: Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.

 

HNB Access Network Elements

This section provides the brief description and functionality of various network elements involved in the UMTS Femto access network. The HNB access network includes the following functional entities:

 

•	Home NodeB

•	Security Gateway (SeGW)

•	HNB Gateway (HNB-GW)

•	HNB Management System (HMS)

 

Home NodeB

A Home NodeB (HNB) is the a customer premise equipment that offers Uu interface to UE and IuH over IPSec tunnel to HNB-GW for accessing UMTS Core Network (PS or CS) in Femtocell access network.

It also provides the support to HNB registration and UE registration over IuH with HNB-GW. Apart from these functions HNB also supports some RNC like functions as given below:

•	RAB management functions

•	Radio Resource Management functions

•	Iu Signalling Link management

•	GTP-U Tunnels management

•	Buffer Management

•	Iu U-plane frame protocol initialization

•	Mobility management functions

•	Security Functions

•	Service and Network Access functions

•	Paging co-ordination functions

•	UE Registration for HNB

•	IuH user-plane Management functions

 

Security Gateway (SeGW)

Security Gateway is a logical entity in Cisco HNB-GW. Basic function of this entity are; 1) authentication of HNB and 2) providing access to HMS and HNB-GW

This entity terminates the secure tunnelling for IuH and TR-069 between HNB and HNB-GW and HMS respectively.

In this implementation it is an optional element which is situated on HNB-GW.

 

HNB Gateway (HNB-GW)

The HNB-GW provides the access to Femto user to UMTS core network. It acts as an access gateway to HNB and concentrates connections from a large amount of HNBs. The IuH interface is used between HNB and HNB-GW and HNB-GW connects with the Core Networks (CS or PS) using the generic Iu (IuCS or IuPS) or Gn interface.

It also terminates Gn and other interfaces from UMTS core networks to provide mobile data services to HNB and to interact with HMS to perform HNB authentication and authorization.

 

HNB Management System (HMS)

It is a network element management system for HNB access. Management interface between HNB and HMS is based on TR-069 family of standards.

It performs following functions while managing HNB access network:

•	Facilitates HNB-GW discovery for HNB

•	Provision of configuration data to the HNB

•	Performs location verification of HNB and assigns appropriate serving elements (HMS, Security Gateway and HNB-GW)

The HNB Management System (HMS) comprises of the following functional entities:

•	File Server: used for file upload or download, as instructed by TR-069 manager

•	TR-069 Manager: Performs CM, FM and PM functionality to the HNB through Auto-configuration server (HMS)

 

Product Specification

This section describes the hardware and software requirement for HNB Gateway.

The following information is located in this section:

•

Licenses

•	Hardware Requirements

•	Operating System Requirements

 

Licenses

The HNB-GW is a licensed product. A session use license key must be acquired and installed to use the HNB-GW service.

The following licenses are available for this product:

•	Cisco PID [ ASR5K-00-FY10P-K9 ] Home Node-B Gateway (HNB-GW) 10K Iuh Sessions, or Starent Part Number [ 600-20-0057 ] Home Node-B Gateway (HNB-GW) 10K Iuh Sessions.

•	Cisco PID [ ASR5K-00-FY01P-K9 ] Home Node-B Gateway (HNB-GW) 1K Iuh Sessions, or Starent Part Number [ 600-20-0058 ] Home Node-B Gateway (HNB-GW) 1K Iuh Sessions.

•	Cisco PID [ ASR5K-00-FY10G-K9 ] Home Node-B Gateway Registered 10K User Sessions, or Starent Part Number [ 600-20-0094 ] Home Node-B Gateway Registered 10K User Sessions.

•	Cisco PID [ ASR5K-00-FY01G-K9 ] Home Node-B Gateway Registered 1K User Sessions, or Starent Part Number [ 600-20-0095 ] Home Node-B Gateway Registered 1K User Sessions.

Depending on your deployment requirement, apart from HNB-GW generic licenses you may need licenses for following service/feature as well:

•	Cisco PID [ ASR5K-00-FY01SR ] Session Recovery, Home Node-B Gateway, 1k Sessions .

•	Cisco PID [ ASR5K-00-CS01I-K9 ] IPSec Encryption, 1k Sessions.

•	Cisco PID [ ASR5K-00-CS10I-K9 ] IPSec Encryption, 10k Sessions.

•	Cisco PID [ ASR5K-00-CSXXDYNR ] IDynamic Radius Extensions (CoA and PoD).

•	Cisco PID [ LIF5K-00-CSXXDYNR ] Dynamic Radius extensions (CoA and PoD) (Failover).

For more information on supported enhanced features and services, refer Features and Functionality section.

 

Hardware Requirements

Information in this section describes the hardware required to enable the HNB-GW service.

 

Platforms

The HNB-GW service operates on the following platforms:

 

•

ASR 5000

 

System Hardware Components

The following application and line cards are required to support HNB-GW services on the system:

 

•	System Management Cards (SMC): Provides full system control and management of all cards within the ASR 5000 platform. Up to two SMC can be installed; one active, one redundant.

•	Packet Services Cards (PSC/PSC2): Within the ASR 5000 platform, PSCs/PSC2s provide high-speed, multi-threaded Bearer context processing capabilities for HNB-GW services. Up to 14 PSCs/PSC2s can be installed, allowing for multiple active and/or redundant cards.

•	Packet Processor Card (PPC): The PPC has features a quad-core x86 2.5Ghz CPU and 16GB of RAM. The processor runs a single copy of the operating system.The operating system running on the PPC treats the dual-core processor as a 2-way multi-processor.

Within the ASR 5000 platform, PPCs provide medium to high-speed, multi-threaded Bearer context processing capabilities for HNB-GW services. Up to 14 PPCs can be installed, allowing for multiple active and/or redundant cards.

•	Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SPCs/SMCs, SPIOs provide connectivity for local and remote management, central office (CO) alarms. Up to two SPIOs can be installed; one active, one redundant.

•	Line Cards: The following rear-loaded line cards are currently supported by the system:

•

Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind PSCs, these cards provide the physical interfaces to elements in the Femto UMTS network. Up to 26 line cards should be installed for a fully loaded system with 13 active PSCs/PSC2, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs/PSC2s do not require line cards.

•	Quad Gig-E Line Cards (QGLCs): The 4-port Gigabit Ethernet line card is used in the ASR 5000 system only and is commonly referred to as the Quad-GigE Line Card or the QGLC. The QGLC is installed directly behind its associated PSC/PSC2 to provide network connectivity to the packet data network.

•

10 Gig-E Line Cards (XGLCs): The 10 Gigabit Ethernet Line Card is used in the ASR 5000 system only and is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ASR 5000 and the packet core network, and reduces the number of physical ports needed on the ASR 5000.

The one-port XGLC supports the IEEE 802.3-2005 revision which defines full duplex operation of 10 Gigabit Ethernet.

The XGLC is configured and monitored via the System Management Card (SMC) over the system’s control bus. Both SMCs must be active to maintain maximum forwarding rates.

•	The ASR 5000 provides support for following type of optical fiber line cards: OLC and OLC2.

•	Optical (ATM over SDH/SONET) Line Cards (OLC or OLC2): ATM/POS OC-3 Single Mode or Multi-Mode optical fiber line cards providing SS7 broadband signaling, e.g., SIGTRAN over ATM via E1/DS1 (T1) signaling.

•	Channelized Line Cards (CLC or CLC2): STM-1/OC-3 provides Frame Relay over SDH/SONET signaling

Important: Depending on the HNB-GW network environment, the system supports multiple types of line cards simultaneously if needed:

•

Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SPCs/SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100/Ethernet 1000/Quad-Gig-E/10-Gig-E line cards and every PSC/PSC2 in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSCs/PSC2.

Important: Additional information pertaining to each of the application and line cards required to support Femto UMTS services is located in the Hardware Platform Overview chapter of the Product Overview Guide.

 

Operating System Requirements

The HNB-GW is available for ASR 5000 running StarOS™ Release 10.0 or later.

 

Network Deployment and Interfaces

This section describes the supported interfaces and deployment scenario of HNB-GW in 3G Femto access network.

The following information is provided in this section:

•	HNB Gateway in 3G UMTS Network

•	Supported Interfaces

 

HNB Gateway in 3G UMTS Network

The following figure displays simplified network views of the HNB-GW in an Femto access network accessing UMTS PS or CS Core Network.

HNB-GW in UMTS Network and Interfaces

 

Supported Interfaces

In support of both mobile and network originated subscriber UE contexts, the HNB-GW provides the following network interface support:

•	IuH Interface: This interface is the reference point for the control plane protocol between Home NodeB and HNB-GW. IuH has SCTP as transport layer protocol for guaranteed delivery of signaling messages between HNB-GW and Home NodeB. IPSec IKEv2 can be used for security purpose in unsecured network.

This is the interface used by the HNB-GW to communicate with HNB on the same Femtocell Access Network. This interface serves as path for establishing and maintaining subscriber UE contexts.

One instance of IuH endpoint can be configured which can supprot multiple IuH session per system context.

•

IuCS: This interface is the reference point in UMTS which links the HNB-GW, which acts as an RNC (Radio Network Controller), with a Mobile Switching Centre (3G MSC) in the 3G UMTS Femtocell Access Network. This interface provides an IuCS over IP or IuCS over ATM (IP over AAL5 over ATM) interface between the MSC and the RNC (HNB-GW) in the 3G UMTS Femtocell Access Network. RAN Application Part (RANAP) is the control protocol that sets up the data plane (RTP) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuCS (control) for the HNB-GW.

This is the interface used by the HNB-GW to communicate with 3G MSC on the same Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining the CS access for Femtocell UE to circuit switched UMTS core networks

One or more IuCS interfaces can be configured per system context.

•

IuPS: This interface is the reference point between HNB-GW and SGSN. This interface provides an IuPS over IP or IuPS over ATM (IP over AAL5 over ATM) interface between the SGSN and the RNC (HNB-GW) in the 3G UMTS Femtocell Access Network. RAN Application Part (RANAP) is the control protocol that sets up the data plane (GTP-U) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuPS-C (control) for the HNB-GW.

This is the interface used by the HNB-GW to communicate with SGSN on the same Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining the PS access for Femtocell UE to packet switched UMTS core networks.

One or more IuPS interfaces can be configured per system context.

•

Iu-Flex: This interface is the reference point in UMTS which links the HNB-GW, which acts as an RNC (Radio Network Controller), with a Mobile Switching Centre (3G MSC) in the 3G UMTS Femtocell Access Network. This interface provides an IuCS over IP or IuCS over ATM (IP over AAL5 over ATM) interface between the MSC and the RNC (HNB-GW) in the 3G UMTS Femtocell Access Network. RAN Application Part (RANAP) is the control protocol that sets up the data plane (RTP) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuCS (control) for the HNB-GW.

This is the interface used by the HNB-GW to communicate with 3G MSC on the same Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining the CS access for Femtocell UE to circuit switched UMTS core networks

One or more IuCS interfaces can be configured per system context.

•	RADIUS: This interface is the reference point between a Security Gateway (SeGW) and a 3GPP AAA Server or 3GPP AAA proxy (OCS/CGF/AAA/HSS) over RADIUS protocol for AAA procedures for Femto user.

In the roaming case, the 3GPP AAA Proxy can act as a stateful proxy between the SeGW and 3GPP AAA Server.

The AAA server is responsible for transfer of subscription and authentication data for authenticating/authorizing user access and UE authentication. The SeGW communicates with the AAA on the PLMN using RADIUS protocol.

One or more RADIUS interfaces can be configured per system context.

•

TR-069: This interface is an application layer protocol which is used for remote configuration of terminal devices, such as DSL modems, HNBs and STBs. TR-069 provides an auto configuration mechanism between the HNB and a remote node in the service provider network termed the Auto Configuration Server. The standard also uses a combination of security measures including IKEv2 (Internet Key Exchange v2) and IPsec (IP Security) protocols to authenticate the operator and subscriber and then guarantee the privacy of the data exchanged.

One TR-069 interface can be configured per HNB node.

 

Features and Functionality - Base Software

 

This section describes the features and functions supported by default in base software on HNB-GW service and do not require any additional license to implement the functionality with the HNB-GW service.

Following features and supports are discussed in this section:

•	AAA Server Group Support

•	AAL2 Establish and Release Support

•	Access Control List Support

•	ANSI T1.276 Compliance

•	ATM VC Management Support

•	Congestion Control and Management Support

•	Emergency Call Handling

•	GTP-U Tunnels Management Support

•	HNB-UE Access Control

•	HNB Management Function

•	Multiple MSC Selection without Iu-Flex

•	Intra-Domain Multiple CN Support Through Iu-Flex

•	Iu Signalling Link Management Support

•	IuH User-Plane Transport Bearer Handling Support

•	Network Access Control Functions through SeGW

•	QoS Management with DSCP Marking

•	RADIUS Support

•	System Management Features

•	UE Management Function for Pre-Rel-8 UEs

 

AAA Server Group Support

Value-added feature to enable VPN service provisioning for enterprise or MVNO customers. Enables each corporate customer to maintain its own AAA servers with its own unique configurable parameters and custom dictionaries.

This feature provides support for up to 800 AAA (RADIUS and Diameter) server groups and 800 NAS IP addresses that can be provisioned within a single context or across the entire chassis. A total of 128 servers can be assigned to an individual server group. Up to 1,600 accounting, authentication and/or mediation servers are supported per chassis and may be distributed across a maximum of 1,000 nodes. This feature also enables the AAA servers to be distributed across multiple nodes within the same context.

Important: For more information on AAA Server Group configuration, refer AAA and GTPP Interface Administration and Reference.

 

AAL2 Establish and Release Support

Support to establish and release of ATM adaptation layer 2 (AAL2) channel within an ATM virtual connection by the HNB-GW in complete or partial compliance with the following standards:

•	3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)

•	3GPP TS 25.415 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols (Release 8)

•	3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)

•	3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	ITU-T Recommendation Q.2630.1: AAL type2 signalling protocol (Capability Set 1)

•	ITU-T Recommendation Q.2630.2: AAL type2 signalling protocol (Capability Set 2)

•	ITU-T Recommendation I.363.2 B: ISDN ATM Adaptation Layer (AAL) Specification: Type 2 AAL

•	ITU-T Recommendation I.366.1: Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2

The HNB-GW connects to core network elements like MSC and SGSN over IuCS and IuPS interfaces respectively. The Iu interface towards core network elements could either by IP based or ATM based. To provide ATM based interface support, Cisco HNB-GW provides AAL2 support on ASR 5000 platform in order to establish a voice bearer with MSC.

 

Access Control List Support

Access Control Lists provide a mechanism for controlling (i.e permitting, denying, redirecting, etc.) packets in and out of the system.

IP access lists, or Access Control Lists (ACLs) as they are commonly referred to, are used to control the flow of packets into and out of the system. They are configured on a per-context basis and consist of “rules” (ACL rules) or filters that control the action taken on packets that match the filter criteria

Once configured, an ACL can be applied to any of the following:

 

•	An individual interface

•	All traffic facilitated by a context (known as a policy ACL)

•	An individual subscriber

•	All subscriber sessions facilitated by a specific context

There are two primary components of an ACL:

 

•	Rule: A single ACL consists of one or more ACL rules. As discussed earlier, the rule is a filter configured to take a specific action on packets matching specific criteria. Up to 128 rules can be configured per ACL.

Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.

•	Rule Order: A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.

Important: For more information on Access Control List configuration, refer IP Access Control List chapter in System Administration Guide.

 

ANSI T1.276 Compliance

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.

ANSI T1.276 specifies several measures for password security.

These measures include:

 

•	Password strength guidelines

•	Password storage guidelines for network elements

•	Password maintenance, e.g. periodic forced password changes

These measures are applicable to the ASR 5000 and the Web Element Manager since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.

 

ATM VC Management Support

Support for Asynchronous Transfer Mode (ATM) virtual circuits (VC) management function of AAL2 and AAL5 protocol by the HNB-GW in accordance with the following standards:

•	3GPP TR 29.814 V7.1.0 (2007-06): 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals Feasibility Study on Bandwidth Savings at Nb Interface with IP transport (Release 7)

HNBGW supports PVC (permanent virtual circuits) connections with CN nodes for AAL2 and AAL5 type of traffic. The Common Part Sublayer (CPS) payload which is carried out by the AAL2 protocol over ATM is also configurable with this feature. It provides the dynamic Common Part Sublayer (CPS) payload configuration for AAL2 protocol traffic over ATM for negotiation between HNB-GW and MSC during call. Default size for payload is 45 but values may range from 1 to 64 Bytes. This feature makes the operator to choose the CPS payload size dynamically.

 

Congestion Control and Management Support

Congestion Control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

 

•

Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.

A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.

•	Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.

•	Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.

•	Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.

Important: For more information on Congestion Control support, refer Congestion Control chapter in System Administration Guide.

 

Emergency Call Handling

The HNB-GW supports the handling of Emergency call in accordance with the following standards:

•	3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	3GPP TS 33.102 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture Release 9)

The HNB-GW provides access for all UE/HNB when emergency call initiated. In case of non CSG UEs or non CSG HNBs, after Emergency call is finished, the context established between the HNB and operator’s core network entities for UEs who can not get access over the HNB is released to prevent the UE from accessing non-emergency services.

HNB-GW handles the emergency call in following way:

•	Authentication: In case of emergency call, HNB sends a UE REGISTRATION REQUEST message with “Registration cause” as emergency call and excludes the “UE Permanent identity” (i.e IMSI) and HNBGW does not perform access control for emergency call case.

•

Single Iu and Single RAB: In case of emergency call, HNBGW does not allow multiple RABs for UE. This means that UE must have only one Iu connection, either CS or PS, and have only one RAB on that Iu connection. HNB-GW implements “Single IU, Single RAB policy” when UE registration comes with Emergency.

The RUA-CONNECT has an IE called “establishment cause” which can take values as “Normal” or “Emergency”. If UE-registration was due to emergency then RUA-CONNECT must contain “Emergency”. If RUA-CONNECT contains “normal” then HNB-GW rejects it.

While rejecting RUA connection or RAB connection the HNB-GW uses following reject cause:

•	RUA - Misc: unspecified

•	RAB - Misc: unspecified

•	If UE-registration is normal then both (normal and emergency) RUA-CONNECT is allowed.

 

GTP-U Tunnels Management Support

Support to manage the GTP-U tunnels between HNB-GW and GSNs by in accordance with the following standards:

•	3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	3GPP TS 25.468 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

•	3GPP TS 25.469 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 9)

•	3GPP TS 29.060 V9.0.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 9)

HNB-GW supports establishment of GTPU tunnels for each RAB over the IuPS interface. HNB-GW terminates the GTP-U teunnels coming from CN (SGSN) and initiates seperate GTP-U tunnel towards HNB.

 

HNB-UE Access Control

UE/HNB access control support in 3G UMTS HNB Access Network is provided on HNB-GW through IMSI White list database and AAA attribute processing. This feature is in accordance with following standards:

•	3GPP TS 23.003 V8.9.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)

•	3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)

•	IETF RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

The HNB-GW provides UE registration and de-registration procedure for the HNB to convey Rel-8 UE identification data to the HNB-GW in order to perform access control for the UE in the HNB-GW. The UE Registration also establishes a UE specific context identifier to be used between HNB and HNB-GW. The procedure triggered when the UE attempts to access the HNB via an initial NAS message and there is no context in the HNB allocated for that UE.

For pre-Release 8 UEs, which do not support CSG and does not listen for CSG-ID, the HNB-GW ensures that a UE is authorized to access a particular Femtocell. To perform access control check for pre-Release 8 UE, HNB-GW maintains a per-HNB Whitelist. This whitelist is consist of IMSIs which are allowed to access that particular HNB. The whitelist is stored in the HMS and is downloaded to HNB-GW when HNB-REGISTRATION procedure happens.

 

HNB Management Function

Support for HNB registration and de-registration in 3G UMTS HNB Access Network accordance with the following standards:

•	3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)

•	IETF RFC 4960, Stream Control Transmission Protocol, December 2007

The HNB-GW provides HNB registration and de-registration procedure to register the HNB with the HNB-GW. This procedure enables the HNB-GW to provide service and core network connectivity for the HNB. On HNB-GW node this procedure is the first HNBAP procedure triggered after the SCTP association has become operational between HNB and HNB-GW.

HNB management function processes the HNB/UE access control procedure through White-List processing on HNB-GW node. Dynamic update of White-List gives the dynamic HNB management ability to HNB-GW.

 

Multiple MSC Selection without Iu-Flex

Support for multiple MSC selection in a CS core network is provided with this feature support.

HNBGW can connect to multiple MSC and SGSN through Iu-Flex or LAC mapping. This feature implements the multiple MSC selection using LAC.

For this support the HNB-GW uses HNB's LAC, received during registration procedure in HNB_REGISTER_REQUEST message, to distribute RANAP-Initial UE message to an MSC. It maps the LAC with MSC point code and a set of LACs configured for each MSC, connected to the HNB-GW.

In the HNBGW, to select an MSC based on the LAC the following algorithm is used:

•	If both Iu-Flex and LACs are configured for a MSC, then Iu-Flex is used to select a MSC.

•	If only Iu-Flex is configured then Iu-Flex is used for selecting MSC.

•	If only LACs are configured then MSC is selected using LAC from HNB.

•	If both Iu-Flex and LACs are not configured in the HNBGW, it selects default MSC.

 

Intra-Domain Multiple CN Support Through Iu-Flex

Iu-Flex is the routing functionality for intra domain connection of HNB-GW nodes to multiple CN nodes (MSC/SGSN). It provides a routing mechanism and related functionality on HNB-GW to enable it to route information of different Core Network (CN) nodes with in the CS or PS domain. It is implemented in accordance with the following standards:

•	3GPP TS 23.236 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes (Release 9)

•	3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

HNBGW supports Iu-Flex routing mechanism and other applications like many-to-many relation and load-sharing between CN nodes with HNB-GW and CN node pooling. This mechanism provides following benefits to network operator:

•	Eliminates the single point of failure between an RNC/HNB-GW and a CN Node.

•	Ensures geographical redundancy, as a pool can be distributed across sites.

•	Minimizes subscriber impact during service, maintenance, or node additions or replacements.

•	Increases overall capacity via load sharing across the MSCs/SGSNs in a pool.

•	Reduces the need/frequency for inter-CN node RAUs. This substantially reduces signaling load and data transfer delays.

•	Supports load redistribution with the MSC/SGSN offloading procedure.

To incorporate the concept of multiple CN nodes, Iu-Flex introduces the concept of “pool-areas” which is enabled by the routing mechanism in HNB GW. A pool-area is served by multiple CN nodes (MSCs or SGSNs) in parallel which share the traffic of this area between each other. Furthermore, pool-areas may overlap. From a RAN perspective a pool-area comprises all LA(s)/RA(s) of one or more RNC/BSC or HNBGW that are served by a certain group of CN nodes in parallel. One or more of the CN nodes in this group may in addition serve LAs/RAs outside this pool-area or may also serve other pool-areas. This group of CN nodes is also referred to as MSC pool or SGSN pool respectively.

The Iu-Flex enables a few different application scenarios with certain characteristics. The service provision by multiple CN nodes within a pool-area enlarges the served area compared to the service area of one CN node. This results in reduced inter CN node updates, handovers and relocations and it reduces the HLR/HSS update traffic. The configuration of overlapping pool-areas allows to separate the overall traffic into different UE moving pattern, e.g. pool-areas where each covers a separate residential area and all the same city centre. Other advantages of multiple CN nodes in a pool-area are the possibility of capacity upgrades by additional CN nodes in the pool-area or the increased service availability as other CN nodes may provide services in case one CN node in the pool-area fails.

 

Iu Signalling Link Management Support

Support for Iu signal link management function for HNB-GW in accordance with the following standards:

•	3GPP TS 25.412 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signalling transport (Release 8)

•	3GPP TS 25.413 V7.9.0 (2008-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 7)

•	3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)

HNBGW supports RANAP protocol for management of IuPS/IuCS connections. The IU connection on the IuPS/IuCS interface is realized using an SCCP connection towards SGSN/MSC. The SCCP could be over SIGTRAN or ATM.

 

IuH User-Plane Transport Bearer Handling Support

Support for transfer of CS as well as PS data over IP on the IuH interface:

•	3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)

HNBGW supports GTP-U v1 for PS traffic transport and RTP/RTCP for CS traffic transport on IuH interface. HNBGW terminates the GTPU tunnels and RTP sessions at itself for each tunnel/session between CN and HNB.

 

Network Access Control Functions through SeGW

These functions enable secure user and device level authentication between the authenticator component of the HNB-GW and a 3GPP HSS/AuC and RADIUS-based AAA interface support.

This section describes following features:

•	Authentication and Key Agreement (AKA)

•	3GPP AAA Server Support

•	X.509 Certificate-based Authentication Support

 

Authentication and Key Agreement (AKA)

HNB-GW provides Authentication and Key Agreement mechanism for user authentication procedure over the HNB Access Network. The Authentication and Key Agreement (AKA) mechanism performs authentication and session key distribution in networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.

The AKA is the procedure that take between the user and network to authenticate themselves towards each other and to provide other security features such as integrity and confidentiality protection.

In a logical order this follows the following procedure:

1.	Authentication: Performs authentication by, identifying the user to the network; and identifying the network to the user.

2.	Key agreement: Performs key agreement by, generating the cipher key; and generating the integrity key.

3.	Protection: When the AKA procedure is performed it protects, the integrity of messages; confidentiality of signalling data; and confidentiality of user data

 

3GPP AAA Server Support

This interface between the SeGW and AAA Server provides a secure connection carrying authentication, authorization, and related information. in accordance with the following standards:

•	3GPP TS 33.320 V9.1.0 (2010-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security of Home Node B (HNB) / Home evolved Node B (HeNB) (Release 9)

This reference point is located between 3GPP AAA Server/Proxy and HNB-GW. The functionality of this reference point is to enable following requirements on SeGW:

•	The SeGW shall be authenticated by the HNB using a SeGW certificate.

•	The SeGW shall authenticate the HNB based on HNB certificate.

•	The SeGW authenticates the hosting party of the HNB in cooperation with the AAA server using EAP-AKA.

•	The SeGW shall allow the HNB access to the core network only after successful completion of all required authentications.

•	Any unauthenticated traffic from the HNB shall be filtered out at the SeGW

 

X.509 Certificate-based Authentication Support

HNB-GW supports X.509 Certificate-based authentication to HNB/UE for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies the standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

 

QoS Management with DSCP Marking

Differentiated Services Code Point (DSCP) marking over IuH interface support in 3G UMTS HNB Access Network is provided on HNB-GW for traffic quality management in accordance with following standards:

•	3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)

•	3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

•	3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)

•	IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

•	IETF RFC 4594, Configuration Guidelines for DiffServ Service Classes

•	IETF RFC 4960, Stream Control Transmission Protocol

In a fixed line-mobile convergence scenario, the user data and signaling traffic from a UE is forwarded by an HNB to HNB-GW over IuH interface. IP is used as network layer for IuH. RTP/ RTCP or GTP over UDP/IP form transport for user data. SCTP/IP is used for control signaling over IuH.

These data and control packets traverse public Internet before reaching HNB-GW and vice-a-versa for the downlink traffic. RTP typically carries jitter-sensitive real-time media data such as voice and video. RTCP carries media reception/ transmit feedback that is not delay sensitive. GTP carries generic, non-media data. These various traffic types, each, deserve different QoS handling by the IP nodes they traverse between HNB and HNB-GW. Thus DSCP codes are assigned in the IP headers of the traffic such that intermediate IP nodes can provide differentiated QoS treatment to the traffic for an acceptable end-user experience.

HNB-GW supports DSCP marking of the traffic on IuH for downlink traffic towards HNB and for uplink traffic towards MSC when IP transport is used for IuCS or IuPS.

 

RADIUS Support

In HNB-GW the RADIUS support provides a mechanism for performing authorization and authentication for subscriber sessions based on the following standards:

 

•	RFC-2618, RADIUS Authentication Client MIB, June 1999

•	RFC-2620, RADIUS Accounting Client MIB, June 1999

•	RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

•	RFC-2866, RADIUS Accounting, June 2000

•	RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000

•	RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000

•	RFC-2869, RADIUS Extensions, June 2000

Within context contexts configured on the system, there are AAA and RADIUS protocol-specific parameters that can be configured. The RADIUS protocol-specific parameters are further differentiated between RADIUS Authentication server RADIUS Accounting server interaction.

Among the RADIUS parameters that can be configured are:

 

•	Priority: Dictates the order in which the servers are used allowing for multiple servers to be configured in a single context.

•

Routing Algorithm: Dictate the method for selecting among configured servers. The specified algorithm dictates how the system distributes AAA messages across the configured AAA servers for new sessions. Once a session is established and an AAA server has been selected, all subsequent AAA messages for the session will be delivered to the same server.

In the event that a single server becomes unreachable, the system attempts to communicate with the other servers that are configured. The system also provides configurable parameters that specify how it should behave should all of the RADIUS AAA servers become unreachable.

Important: For more information on RADIUS AAA configuration, refer AAA and GTPP Interface Administration and Reference.

 

UE Management Function for Pre-Rel-8 UEs

Support for Pre-Rel-8 UE registration and de-registration in 3G UMTS HNB Access Network in accordance with the following standards:

•	3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)

•	3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)

•	IETF RFC 4960, Stream Control Transmission Protocol, December 2007

The HNB-GW provides UE registration and de-registration procedure for the HNB to convey pre-Rel-8 UE identification data to the HNB-GW in order to perform access control for the UE in the HNB-GW. The UE Registration also establishes a UE specific context identifier to be used between HNB and HNB-GW. The procedure triggered when the UE attempts to access the HNB via an initial NAS message and there is no context in the HNB allocated for that UE.

 

System Management Features

This section describes following features:

•	Management System Overview

•	Bulk Statistics Support

•	Threshold Crossing Alerts (TCA) Support

•	ANSI T1.276 Compliance

 

Management System Overview

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

Operation and Maintenance module of ASR 5000 offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces. These include:

•	Using the command line interface (CLI)

•	Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces

•	Local login through the Console port on SPIO card using an RS-232 serial connection

•	Using the Web Element Manager application

•	Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000

•	Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO

•	Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)

•	Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management

•	Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities

•	Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.

Element Management System

Important: HNB-GW management functionality is enabled for console-based access by default. For GUI-based management support, refer WEM Installation and Administration Guide.

Important: For more information on command line interface based management, refer Command Line Interface Reference.

 

Bulk Statistics Support

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a partial list of supported schemas:

•	System: Provides system-level statistics

•	Card: Provides card-level statistics

•	Port: Provides port-level statistics

•	GTP-U: Provides GPRS Tunneling Protocol - User message statistics

•	HNB-AAL2: Provides ATM adaptation layer 2 (AAL2) protocol level-statistics

•	HNB-ALCAP: Provides Access Link Control Application Part (ALCAP) service-level statistics

•	CS-Network-RANAP: Provides RANAP-level statistics for HNB-CS network

•	CS-Network-RTP: Provides RTP protocol-level statistics for HNB-CS network

•	HNB-GW-HNBAP: Provides HNBAP-level statistics for HNB-GW service

•	HNB-GW-RANAP: Provides RANAP-level statistics for HNB-GW service

•	HNB-GW-RTP: Provides RTP protocol-level statistics for HNB-GW service

•	HNB-GW-RUA: Provides RUA protocol-level statistics for HNB-GW service

•	HNB-GW-SCTP: Provides HNB -SCTP protocol-level statistics

•	PS-Network--RANAP: Provides RANAP-level statistics for HNB-PS network

•	SCCP: Provides SCCP service-level statistics at system-level

•	SS7Link: Provides SS7 link configuration related statistics at system-level

•	SS7 Routing Domain: Provides SS7 Routing domain configuration related statistics at system level

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the IMG or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, IMG host name, IMG uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

 

Threshold Crossing Alerts (TCA) Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

The following thresholding models are supported by the system:

•	Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

•	Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

•	SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

•	Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

Logs are supported in both the Alert and the Alarm models.

•

Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

The Alarm System is used only in conjunction with the Alarm model.

 

Important: For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.

 

ANSI T1.276 Compliance

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.

ANSI T1.276 specifies several measures for password security. These measures include:

•	Password strength guidelines

•	Password storage guidelines for network elements

•	Password maintenance, e.g. periodic forced password changes

These measures are applicable to the ASR 5000 Platforms and the Web Element Manager since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.

 

Features and Functionality - Optional Enhanced Feature Software

This section describes the optional enhanced features and functions for HNB-GW service.

Important: Some of the following features may require the purchase of an additional license to implement the functionality with the HNB-GW service.

This section describes following features:

 

•	Dynamic RADIUS Extensions (Change of Authorization)

•	IP Security (IPSec)

•	Session Recovery Support

•	Web Element Management System

 

Dynamic RADIUS Extensions (Change of Authorization)

Dynamic RADIUS extension support provide operators with greater control over subscriber PDP contexts by providing the ability to dynamically redirect data traffic, and or disconnect the PDP context.

This functionality is based on the RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003 standard.

The system supports the configuration and use of the following dynamic RADIUS extensions:

•

Change of Authorization: The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session.

•	Disconnect Message: The DM message is used to disconnect subscriber sessions in the system from a RADIUS server. The DM request message should contain necessary attributes to identify the subscriber session.

The above extensions can be used to dynamically re-direct subscriber PDP contexts to an alternate address for performing functions such as provisioning and/or account set up. This functionality is referred to as Session Redirection, or Hotlining.

Session redirection provides a means to redirect subscriber traffic to an external server by applying ACL rules to the traffic of an existing or a new subscriber session. The destination address and optionally the destination port of TCP/IP or UDP/IP packets from the subscriber are rewritten so the packet is forwarded to the designated redirected address.

Return traffic to the subscriber has the source address and port rewritten to the original values. The redirect ACL may be applied dynamically by means of the Radius Change of Authorization (CoA) extension.

Important: For more information on dynamic RADIUS extensions support, refer CoA, RADIUS, And Session Redirection (Hotlining) in this guide.

 

IP Security (IPSec)

IP Security provides a mechanism for establishing secure tunnels from mobile subscribers to pre-defined endpoints (i.e. enterprise or home networks) in accordance with the following standards:

•	RFC 2401, Security Architecture for the Internet Protocol

•	RFC 2402, IP Authentication Header (AH)

•	RFC 2406, IP Encapsulating Security Payload (ESP)

•	RFC 2409, The Internet Key Exchange (IKE)

•	RFC-3193, Securing L2TP using IPSEC, November 2001

IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways.

IPSec tunnel supports AAA and DHCP address overlapping. Address overlapping is meant for multiple customers using the same IP address for AAA/DHCP servers. The AAA and DHCP control messages are sent over IPSec tunnels and AAA/DHCP packets required to be encrypted are decided as per the ACL configuration done for specific session.

Important: For more information on IPSec configuration, refer HNB-GW Service Configuration section.

 

Session Recovery Support

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active Control Processor (CP) being used.

Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

The additional hardware resources required for session recovery include a standby System Processor Card (SPC) and a standby packet processing card.

There are two modes for Session Recovery.

 

•

Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.

•

Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processing cards to ensure task recovery.

Important: For more information on this feature, refer Session Recovery chapter in System Administration Guide.

 

Web Element Management System

Provides a Graphical User Interface (GUI) for performing Fault, Configuration, Accounting, Performance, and Security (FCAPS) management of the ASR 5000.

The Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) management capability for the system.

For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more systems via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.

The following figure demonstrates various interfaces between the Cisco Web Element Manager and other network components.

Web Element Manager Network Interfaces

Important: For more information on WEM support, refer WEM Installation and Administration Guide.

 

How HNB-GW Works

This section provides information on the function and procedures of the HNB-GW in an wireless network and presents message flows for different stages of session setup.

The following procedures are supported in this release:

•	HNB Provisioning and Registration Procedure

•	UE Registration Procedure

•	Iu Connection Procedures

•	Paging and Serving RNS Relocation Procedures

•	RANAP Reset Procedures

 

HNB Provisioning and Registration Procedure

This section describes the call flow for HNB provisioning and registration procedure.

The following figure and the text that follows describe the message flow for HNB provisioning and registration with HNB-GW procedure.

HNB Provisioning and Registration Setup Call Flow

1.	HNB initialization is performed to obtain HNB configuration from the HNB Management System (HMS). Similarly, HNB-GW discovery is performed to obtain the initial serving HNB-GW information.

2.	A secure tunnel is established from the HNB to the Security Gateway.

3.

Location verification shall be performed by the HMS based on information sent by the HNB (e.g. macro neighbor cell scans, global navigational satellite system type of information etc.). HMS determines the serving elements and provides the HNB-GW, HMS and Security Gateway to the HNB. The HMS also provisions configuration parameters to the HNB only after successful location verification in the HMS.

4.	Reliable transport setup (SCTP) completed and the HNB sets up a SCTP transport session to a well-defined port on the serving HNB-GW. HNB Registration procedure started.

5.	The HNB attempts to register with the serving HNB-GW using a HNB-REGISTER-REQUEST message. This message may contains:

•	HNB Location Information: The HNB provides location information via use of one or more of the following mechanisms:

•	detected macro coverage information (e.g. GERAN and/or UMTS cell information)

•	geographical co-ordinates (e.g. via use of GPS, etc)

•	Internet connectivity information (e.g. IP address).

•	HNB Identity: the HNB has a globally unique and permanent identity.

•	HNB Operating Parameters: Such as the selected LAC, RAC, SAC, etc.

6.

The HNB-GW uses the information from the HNB-REGISTER-REQUEST message to perform access control of the HNB (e.g. whether a particular HNB is allowed to operate in a given location, etc). If the HNB-GW accepts the registration attempt the PLMN-ID received in the request shall be used to lookup the PLMN to RNC id mapping table and corresponding RNC-ID shall be returned in the HNB-REGISTER-ACCEPT message else the HNB-GW may reject the registration request (e.g. due to network congestion, blacklisted HNB, unauthorized HNB location, etc). In reject case, the HNB-GW shall respond with a HNB-REGISTER-REJECT indicating the reject cause.

Important: The HNB shall start broadcasting only after successful registration with the HNB-GW.

 

UE Registration Procedure

This section describes the UE registration procedures for HNB provides means for the HNB to convey UE identification data to the HNB-GW in order to perform access control for the UE in the HNB GW. The UE Registration also informs the HNB-GW of the specific HNB where the UE is located.

The UE registration procedure generally triggers when the UE attempts to access the HNB through an initial NAS message and there is no context id in the HNB for specific UE.

UE Registration procedure is described for following scenarios:

•	UE Registration Procedure of Non-CSG UEs or Non-CSG HNBs

 

UE Registration Procedure of Non-CSG UEs or Non-CSG HNBs

This procedure is applicable for non-CSG UEs or HNBs.

The following figure and the text that follows describe the message flow for UE registration procedure of Non-CSG UEs or Non-CSG HNBs:

UE Registration Call Flow for Non-CSG UEs or Non-CSG HNBs

1.	Upon camping on the HNB, the UE initiates an initial NAS procedure (e.g. LU Procedure) by establishing an RRC connection with the HNB. UE capabilities are reported to the HNB as part of the RRC Connection establishment procedure.

2.	The UE then transmits a RRC Initial Direct Transfer message carrying the initial NAS message (e.g. Location Updating Request message) with identity (IMSI or TMSI).

3.

The HNB checks UE capabilities provided in step 1, if these indicate that CSG is not supported and if the identity of the UE (provided during RRC Connection Establishment) is unknown at the HNB being accessed, i.e. no Context id exists for the UE, the HNB initiates UE registration towards HNB-GW (step 6-8).

4.

Before starting the UE Registration procedure, HNB optionally triggers the Identification procedure asking for the UE IMSI, if such identity is not provided during the RRC Connection Establishment. If the HNB has a context id for the UE, the UE registration procedure is not performed nor the Identification procedure.

5.	The HNB may optionally perform access control based on IMSI and provided access control list.

6.	The HNB attempts to register the UE on the HNB-GW by transmitting the UE-REGISTER-REQUEST. The message contains at a minimum:

•	UE Identity: IMSI of the (U)SIM associated with the UE and the indication about UE capabilities provided in step 1.

Important: The UE IMSI provided in the UE-REGISTER message is unauthenticated.

7.	The HNB-GW checks UE capabilities and if these indicate that CSG is not supported the HNB-GW shall perform access control for the particular UE attempting to utilize the specific HNB.

8.

If the HNB-GW accepts the UE registration attempt it shall allocate a context-id for the UE and respond with a UE-REGISTER-ACCEPT message, including the context-id, to the HNB. If the HNB-GW chooses to not accept the incoming UE registration request then the HNB-GW shall respond with a UE-REGISTRATION-REJECT message.

9.	The HNB then sends a RUA (RANAP User Adaptation) CONNECT message containing the RANAP Initial UE message to HNB-GW.

10.	The reception of the RUA CONNECT message at the HNB-GW triggers the setup of SCCP connection by the HNB-GW towards the CN. HNB-GW forwards the Initial UE Message to CN.

11.	The CN response with a SCCP Connection Confirm message to HNB-GW.

12.	The UE then continue with the NAS procedure (e.g. Location Updating procedure) towards the CN, via HNB and the HNB-GW.

 

Iu Connection Procedures

This section describes call flow for Iu connection procedures on HNB-GW.

Following procedure call flows are described for Iu connection procedures between HNB, HNB-GW, and SGSN/MSC in core network:

•	Iu Connection Establishment Procedure

•	Network Initiated Iu Connection Release Procedure

 

Iu Connection Establishment Procedure

This procedure is applicable for establishment of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.

The following figure and the text that follows describe the message flow for an Iu connection establishment procedure.

Iu Connection Establishment Call Flow

1.	Upon receiving of UE-REGISTER-ACCEPT message from HNB-GW, the HNB then sends a RUA CONNECT message to HNB-GW containing the RANAP Initial UE message.

2.	The reception of the RUA CONNECT message at the HNB-GW triggers the setup of SCCP connection by the HNB-GW towards the CN (SGSN/MSC). HNB-GW forwards the Initial UE Message.

3.	The CN responses with a SCCP Connection Confirm message.

4.	The UE then continue with the authentication and security procedures towards the CN, via HNB and the HNB-GW.

5.	The SGSN/MSC performs Direct Transfer procedure with HNB-GW and sends SCCP-DATA-FORM1 REQ to HNB-GW.

6.	The HNB-GW uses the information received in Direct Transfer procedure from CN and forwards the same to HNB through RUA-DIRECT-TRANSFER message.

7.	On successful acceptance of RUA-DIRECT-TRANSFER message the HNB responds to HNB-GW and sends RUA-DIRECT-TRANSFER Response message to HNB-GW.

8.	On reception of successful acceptance of RUA-DIRECT-TRANSFER message from HNB, the HNB-GW sends SCCP-DATA-FORM1 (Direct Transfer) Response message to CN (SGSN/MSC). This completes the establishment of IuH and IuPS/IuCS connection through HNB, HNB-GW, and SGSN/MSC in core network.

 

Network Initiated Iu Connection Release Procedure

This procedure is applicable for release of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.

The following figure and the text that follows describe the message flow for an Iu connection release procedure initiated by CN (SGSN/MSC).

Network Initiated Iu Connection Release Call Flow

1.	User session is established between UE and CN via HNB and HNB-GW over Iu interface and CN (SGSN/MSC) starts RANAP Iu Release procedure with HNB-GW and sends SCCP-DATA-FORM1 REQ with RANAP Iu Release command to HNB-GW.

2.	The HNB-GW uses the information received in SCCP-DATA-FORM1 REQ with RANAP Iu Release procedure from CN and forwards the same to HNB through RUA-DIRECT-TRANSFER message with RANAP Iu Release command.

3.	On reception of RANAP Iu Release command in RUA-DIRECT-TRANSFER message the HNB triggers the RCC Connection Release procedure and responds to HNB-GW with RANAP Iu Release Complete command in RUA-DISCONNECT Response message.

4.	On reception of successful RANAP Iu Release Complete command in RUA-DISCONNECT Response message from HNB, the HNB-GW sends RANAP Iu Release Complete command in SCCP-DATA-FORM1 Response message to CN (SGSN/MSC).

5.

On reception of RANAP Iu Release Complete command in SCCP-DATA-FORM1 Response message from HNB-GW, CN sends SCCP-RELEASED message to HNB-GW and triggers the associated SCCP connection. On reception of SCCP-RELEASED message from CN, the HNB-GW sends RUA-DISCONNECT message to HNB and disconnect the IuH connection with HNB.

6.	After successful completion of RUA-DISCONNECT procedure and IuH connection release, HNB-GW sends SCCP-RELEASE-COMPLETE message to CN and HNB-GW confirms the IuPS/IuCS connection released between HNB-GW and CN.

 

Paging and Serving RNS Relocation Procedures

This section describes the call flow for network-initiated paging and SRNS relocation procedures on HNB-GW.

Following procedure call flows are described for Paging and SRNS relocation procedures between HNB, HNB-GW, and SGSN/MSC in core network:

•	Paging Procedure

•	SRNS Relocation Procedure

 

Paging Procedure

This procedure is applicable for establishment of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.

The following text describes the call flow for Paging procedure on HNB-GW:

1.	HNB-GW receives Paging from SGSN/MSC. HNB-GW finds out if any UE is registered with that IMSI.

2.	If a UE is registered then HNB-GW sends the Paging message to the HNB through which the UE is registered.

3.	If no registered UE is found then HNB-GW finds out the list of HNBs which have IMSI received in the message in their respective Whitelist.

4.	If one or more HNBs were found, and Paging message contained LAI, then HNB-GW compares the HNB’s PLMN-ID and LAC values against LAI received in the Paging. The HNB which do not have matching values is dropped from this list.

5.	If one or more HNBs were found, and Paging message contained RAI, then HNB-GW compares the HNB’s PLMN-ID, LAC and RAC values against RAI received in the Paging. The HNB which do not have matching values is dropped from this list.

6.	If Paging message did not have Paging-area then list of HNBs is same as what was found in step 1 otherwise list of HNBs is as found in step 2 or step 3.

If this list is empty then Paging message is dropped. Otherwise HNB-GW sends Paging message to these HNBs.

 

SRNS Relocation Procedure

This procedure is applicable for intra-CN or inter-CN handover procedure between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.

The following text describes the call flow for SRNS relocation procedure on HNB-GW:

1.	HNB-GW receives Relocation-Request from SGSN/MSC in case subscriber moves from Macrocell to Femtocell in a connected mode.

2.	If the request does not contain IMSI (i.e. for an emergency call), HNB-GW sends Relocation-Request-Reject with an appropriate cause.

3.	. If the request contains IMSI, HNB-GW finds the list of registered HNBs which have this IMSI in their white-list. If there is no such HNB found, HNB-GW sends Relocation-Request-Reject with appropriate cause.

4.	If there is only one such HNB found which has this IMSI in its white-list, HNB-GW sends Relocation-Request to this HNB.

5.	If there are more than one such HNBs found which have this IMSI in their whitelist, then HNBGW looks for Home-HNB for this IMSI. If there are more than one Home-HNB found then HNB-GW sends Relocation-Request-Reject with appropriate cause.

6.	If there are multiple HNBs registered which have this IMSI in their whitelist but only one Home-HNB found, HNBGW sends Relocation-Request to this HNB.

 

RANAP Reset Procedures

This section describes the call flow for various RANAP Reset procedures supported in HNB-GW.

Following procedure call flows are described for RANAP Reset procedures between HNB, HNB-GW, and SGSN/MSC in core network:

•	HNB Initiated RANAP Reset Procedure

•	CN Initiated RANAP Reset Procedure

•	HNB-GW Initiated RANAP Reset Procedure

 

HNB Initiated RANAP Reset Procedure

This procedure is applicable for HNB-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.

The following text describes the call flow for HNB-initiated RANAP Reset procedure:

1.	HNB sends RANAP-RESET command message to HNB-GW for a session.

2.	HNB-GW identifies the all affected Iu connection for particular HNB and sends RESET-ACK message to HNB.

3.	HNB-GW sends SCCP_Released (SCCP-RLSD) message to CN to release the SCCP connection for each affected Iu connection for particular HNB.

4.	CN (SGSN/MSC) sends the SCCP_Release_Complete (SCCP-RLC) message to HNB-GW and release the SCCP connection for requested HNB.

 

CN Initiated RANAP Reset Procedure

This procedure is applicable for HNB-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.

The following text describes the call flow for HNB-initiated RANAP Reset procedure:

1.	CN (SGSN/MSC) sends RANAP-RESET command message to HNB-GW for a session.

2.	On receiving RANAP-RESET from CN, the HNB-GW starts Guard timer for configured timeout duration.

3.	HNB-GW identifies the all affected Iu connections and sends RUA-DISCONNECT message to HNB.

4.	On expiry of Guard timer the HNB-GW sends the RESET-ACK message to CN.

 

HNB-GW Initiated RANAP Reset Procedure

This procedure is applicable for HNB-GW-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.

The HNB-GW initiates RESET towards CN node in following scenarios:

•	The HNB-GW is reloaded or service restarted and SCCP Subsystem Number (SSN) allowed from CN (SGSN/MSC) node is received.

•	The received SSN Prohibited or Point-code Address Inaccessible indication comes for a CN node, HNB-GW start a configurable timer.

•	If SSN allowed indication comes before timer expires, the timer is stopped.

•	On timer expiry HNB-GW deletes all SCCP connections towards the CN node.

•	If SSN Allowed indication comes after timer expiry, HNB-GW sends RANAP-RESET command message to the CN node.

The RANAP-RESET from HNB-GW is sent only if HNB-GW-initiated RANAP-RESET is configured in HNB-GW service.

 

Supported Standards

The HNB-GW complies with the following standards for 3G UMTS Femto wireless data services.

•	3GPP References

•	IETF References

•	ITU-T Recommendations

•	Object Management Group (OMG) Standards

 

3GPP References

 

•	3GPP TS 23.003 V8.9.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)

•	3GPP TS 25.412 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signalling transport (Release 8)

•	3GPP TS 25.413 V7.9.0 (2008-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 7)

•	3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)

•	3GPP TS 25.415 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols (Release 8)

•	3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)

•	3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)

•	3GPP TS 25.468 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN IuH Interface RANAP User Adaptation (RUA) signalling (Release 8)

•	3GPP TS 25.468 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

•	3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

•	3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)

•	3GPP TS 25.469 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 9)

•	3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)

•	3GPP TS 29.060 V9.0.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 9)

•	3GPP TR 29.814 V7.1.0 (2007-06): 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals Feasibility Study on Bandwidth Savings at Nb Interface with IP transport (Release 7)

•	3GPP TS 33.320 V9.1.0 (2010-13): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security of Home Node B (HNB) / Home evolved Node B (HeNB) (Release 9)

•	3GPP TS 23.236 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network(RAN) nodes to multiple Core Network(CN) nodes (Release 8)

 

IETF References

 

•	RFC-768, User Datagram Protocol (UPD), August 1980

•	RFC-791, Internet Protocol (IP), September 1982

•	RFC-793, Transmission Control Protocol (TCP), September 1981

•	RFC-894, A Standard for the Transmission of IP Datagrams over Ethernet Networks, April 1984

•	RFC-1089, SNMP over Ethernet, February 1989

•	RFC-1144, Compressing TCP/IP headers for low-speed serial links, February 1990

•	RFC-1155, Structure & identification of management information for TCP/IP-based internets, May 1990

•	RFC-1157, Simple Network Management Protocol (SNMP) Version 1, May 1990

•	RFC-1212, Concise MIB Definitions, March 1991

•	RFC-1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, March 1991

•	RFC-1215, A Convention for Defining Traps for use with the SNMP, March 1991

•	RFC-1224, Techniques for managing asynchronously generated alerts, May 1991

•	RFC-1256, ICMP Router Discovery Messages, September 1991

•	RFC-1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 1992

•	RFC-1398, Definitions of Managed Objects for the Ethernet-Like Interface Types, January 1993

•	RFC-1418, SNMP over OSI, March 1993

•	RFC-1570, PPP LCP Extensions, January 1994

•	RFC-1643, Definitions of Managed Objects for the Ethernet-like Interface Types, July 1994

•	RFC-1701, Generic Routing Encapsulation (GRE), October 1994

•	RFC-1850, OSPF Version 2 Management Information Base, November 1995

•	RFC-1901, Introduction to Community-based SNMPv2, January 1996

•	RFC-1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1904, Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

•	RFC-1908, Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework, January 1996

•	RFC-1918, Address Allocation for Private Internets, February 1996

•	RFC-1919, Classical versus Transparent IP Proxies, March 1996

•	RFC-2002, IP Mobility Support, May 1995

•	RFC-2003, IP Encapsulation within IP, October 1996

•	RFC-2004, Minimal Encapsulation within IP, October 1996

•	RFC-2005, Applicability Statement for IP Mobility Support, October 1996

•	RFC-2118, Microsoft Point-to-Point Compression (MPPC) Protocol, March 1997

•	RFC 2131, Dynamic Host Configuration Protocol

•	RFC-2136, Dynamic Updates in the Domain Name System (DNS UPDATE)

•	RFC-2211, Specification of the Controlled-Load Network Element Service

•	RFC-2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999

•	RFC-2328, OSPF Version 2, April 1998

•	RFC-2344, Reverse Tunneling for Mobile IP, May 1998

•	RFC-2394, IP Payload Compression Using DEFLATE, December 1998

•	RFC 2401, Security Architecture for the Internet Protocol

•	RFC 2402, IP Authentication Header (AH)

•	RFC 2406, IP Encapsulating Security Payload (ESP)

•	RFC 2409, The Internet Key Exchange (IKE)

•	RFC-2460, Internet Protocol Version 6 (IPv6)

•	RFC-2461, Neighbor Discovery for IPv6

•	RFC-2462, IPv6 Stateless Address Autoconfiguration

•	RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

•	RFC-2486, The Network Access Identifier (NAI), January 1999

•	RFC-2571, An Architecture for Describing SNMP Management Frameworks, April 1999

•	RFC-2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), April 1999

•	RFC-2573, SNMP Applications, April 1999

•	RFC-2574, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), April 1999

•	RFC-4594, Configuration Guidelines for DiffServ Service Classes

•	RFC-2597, Assured Forwarding PHB Group, June 1999

•	RFC-2598, Expedited Forwarding PHB, June 1999

•	RFC-2618, RADIUS Authentication Client MIB, June 1999

•	RFC-2620, RADIUS Accounting Client MIB, June 1999

•	RFC-2661, Layer Two Tunneling Protocol “L2TP”, August 1999

•	RFC-2697, A Single Rate Three Color Marker, September 1999

•	RFC-2698, A Two Rate Three Color Marker, September 1999

•	RFC-2784, Generic Routing Encapsulation (GRE) - March 2000, IETF

•	RFC-2794, Mobile IP Network Access Identifier Extension for IPv4, March 2000

•	RFC-2809, Implementation of L2TP Compulsory Tunneling via RADIUS, April 2000

•	RFC-2845, Secret Key Transaction Authentication for DNS (TSIG), May 2000

•	RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

•	RFC-2866, RADIUS Accounting, June 2000

•	RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000

•	RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000

•	RFC-2869, RADIUS Extensions, June 2000

•	RFC-4960, Stream Control Transmission Protocol

•	RFC-3007, Secure Domain Name System (DNS) Dynamic Update, November 2000

•	RFC-3012, Mobile IPv4 Challenge/Response Extensions, November 2000

•	RFC-3056, Connection of IPv6 Domains via IPv4 Clouds, February 2001

•	RFC-3101 OSPF-NSSA Option, January 2003

•	RFC-3143, Known HTTP Proxy/Caching Problems, June 2001

•	RFC-3193, Securing L2TP using IPSEC, November 2001

•	RFC-3314, Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, September 2002

•	RFC-3316, Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts, April 2003

•	RFC-3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004

•	RFC-3543, Registration Revocation in Mobile IPv4, August 2003

•	RFC 3588, Diameter Base Protocol, September 2003

•	RFC 4006, Diameter Credit-Control Application, August 2005

•	RFC-4306, Internet Key Exchange (IKEv2) Protocol, December 2005

 

ITU-T Recommendations

 

•	ITU-T Recommendation Q.2630.1 - AAL type2 signalling protocol (Capability Set 1)

•	ITU-T Recommendation Q.2630.2 - AAL type2 signalling protocol (Capability Set 2)

•	ITU-T Recommendation I.361 B-ISDN ATM layer specification

•	ITU-T Recommendation I.363.2 B-ISDN ATM Adaptation Layer (AAL) Specification: Type 2 AAL

•	ITU-T Recommendation I.366.1 Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2

•	ITU-T Recommendation Q.2150.1 AAL type 2 signaling transport converter on broadband MTP

•	ITU-T Recommendation E.164 - The international public telecommunication numbering plan

•	ITU-T Recommendation E.191 - B-ISDN addressing

 

Object Management Group (OMG) Standards

 

•	CORBA 2.6 Specification 01-09-35,Object Management Group

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883